Control point control flow #1481
Conversation
An interpreter could do something like:
```
fn f(loc: &Location) {
for i in 0..1000 {
control_point(loc);
if i == hot_threshold {
return;
}
}
}
```
In other words: we start tracing, then `return` before we hit the
control point in the current stack frame again.
ltratt
force-pushed
the
control_point_flow
branch
from
b2b96ee to
bd40930
Compare
|
Here's something I can't immediately explain. Look at this trace (from Notice that Obvious question: should |
|
The trace inputs are taken verbatim from the AOT stackmap. Are you sure |
|
From memory, you can see this in |
| TransitionControlPoint::StopTracing | ||
| } else { | ||
| // ...but in a different frame. | ||
| #[cfg(target_arch = "x86_64")] |
There was a problem hiding this comment.
Nitpick: Here we could check for StackDirection::GrowsDown (defined in regalloc.rs).
There was a problem hiding this comment.
This is definitely a hack but we can't use regalloc here because that backend isn't always guaranteed to be compiled in.
Probably we would need to add a top-level stack_direction function that isn't specific to a compiler backend.
[FWIW, I doubt the code in this PR should survive. It's more of an experiment to show possible problems than code I hope will be merged.]
ykrt/src/mt.rs
Outdated
| } => { | ||
| // We don't care if the thread tracer went wrong: we're not going to use | ||
| // its result anyway. | ||
| thread_tracer.stop().unwrap(); |
There was a problem hiding this comment.
Following from the comment above, I guess the unwrap() should be an ok()?
|
I think so. |
|
I think this is mostly ready now to be turned into a proper PR. Are you taking back over @ltratt or should I be in charge of this PR now? |
|
I think you or Edd should take over now. |
|
Bear with me, there, this needs a little more work. |
(I was getting lots of TraceTooLong crashes, even though we are going to discard the trace).
This reverts commit bedafd9.
|
Closing in favour of #1513. |
This DRAFT PR shows two problems we have right now:
Both tests bork on master.
I have put in what looks like a fix
yk_mt_early_return, but it leads to a segfault in Rust code inearly_return.c(run the test under gdb and you'll see it crashes at a completely innocuous looking place in Rust). This might be a minimal test case of the problems that have recently plagued yklua: certainly, these two tests are things that yklua can do, and that we don't handle properly.Thoughts welcome!